Discussion

For example, most stakeholders would prefer having an application that does exactly what they want it to do, while minimizing the application's development cost and schedule time. Yet, these priorities are often in conflict. Another example is that if we leverage a packaged application, we may be able to deliver a solution faster and at a lower price, but we may have to trade-off many requirements. If instead, we elect to build an application from scratch, it may be able to address every requirement on its wish list, but the budget and project completion date can both be pushed beyond their feasible limits.

Using a component can radically reduce costs and schedule to deliver a certain set of functionality. In many cases we must also compromise on some functional or technical requirements, such as platform support, performance, or foot print (physical size of the application).

To be in a position to balance needs, we must first manage requirements effectively as described in  Supporting Material: Requirement Management. Rather than sending programming teams out to attack each element in a requirements list, we need to understand and prioritize business and stakeholder needs. This means capturing business processes and linking them to projects and software capabilities, which enables us to effectively prioritize projects and requirements, and to modify our prioritization as our understanding of the application increases and stakeholder needs evolve. It also means that we need to involve the customer or customer representative in the project to ensure we understand what their needs are.

At the same time, we need to center development activities around stakeholder needs. For example, by leveraging use-case driven development and user-centered design, our development process can accommodate the evolution of stakeholder needs over the course of the project, as a function of changing business and of our improved understanding of the capabilities that are truly important to the business and the end users. 

Finally, we need to understand what assets are available and balance asset reuse with stakeholder needs. Examples of assets include legacy applications, services, reusable components, and patterns. Reuse of assets can, in many cases, lead to reduced project cost. Reusing proven assets often means higher quality in new applications. The drawback is that, in many cases, we must trade off asset reuse and perfect satisfaction of user needs.Reusing a component may lower development costs for a feature by 80 percent, but this may only address 75 percent of the requirements. So, effective reuse requires us to constantly balance the reuse of assets with evolving stakeholder needs.